The present invention relates to the field of graphical programming, and more particularly to one or more nodes in a graphical program that are operable to access data sources or targets during execution of the graphical program.
Traditionally, high level text-based programming languages have been used by programmers in writing application programs. Many different high level programming languages exist, including BASIC, C, Java, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine language level by translators known as compilers or interpreters. The high level programming languages in this level, as well as the assembly language level, are referred to herein as text-based programming environments.
Increasingly, computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user""s programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.
There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. The task of programming a computer system to model or implement a process often is further complicated by the fact that a sequence of mathematical formulas, mathematical steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a computer system to model such a process. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user""s conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptualize a problem or process and then to program a computer to implement a solution to the problem or process. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his solution, the efficiency with which the computer system can be utilized often is reduced.
Examples of fields in which computer systems are employed to interact with physical systems are the fields of instrumentation, process control, industrial automation, and simulation. Computer measurement and control of devices such as instruments or industrial automation hardware has become increasingly desirable in view of the increasing complexity and variety of instruments and devices available for use. However, due to the wide variety of possible testing and control situations and environments, and also the wide array of instruments or devices available, it is often necessary for a user to develop a custom program to control a desired system.
As discussed above, computer programs used to control such systems traditionally had to be written in text-based programming languages such as, for example, assembly language, C, FORTRAN, BASIC, etc. Traditional users of these systems, however, often were not highly trained in programming techniques and, in addition, text-based programming languages were not sufficiently intuitive to allow users to use these languages without training. Therefore, implementation of such systems frequently required the involvement of a programmer to write software for control and analysis of instrumentation or industrial automation data. Thus, development and maintenance of the software elements in these systems often proved to be difficult.
U.S. Pat. Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,301; and 5,301,336; among others, to Kodosky et al disclose a graphical system and method for modeling a process, i.e., a graphical programming environment which enables a user to easily and intuitively model a process. The graphical programming environment disclosed in Kodosky et al can be considered a higher and more intuitive way in which to interact with a computer. A graphically based programming environment can be represented at a level above text-based high level programming languages such as C, Basic, Java, etc.
The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor. The block diagram may include a plurality of interconnected icons such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables and/or producing one or more output variables. In response to the user constructing a diagram or graphical program using the block diagram editor, data structures may be automatically constructed which characterize an execution procedure which corresponds to the displayed procedure. The graphical program may be compiled or interpreted by a computer.
Therefore, Kodosky et al teaches a graphical programming environment wherein a user places or manipulates icons and interconnects or xe2x80x9cwires upxe2x80x9d the icons in a block diagram using a block diagram editor to create a graphical xe2x80x9cprogram.xe2x80x9d A graphical program for measuring, controlling, or modeling devices, such as instruments, processes or industrial automation hardware, or for modeling or simulating devices, may be referred to as a virtual instrument (VI). Thus, a user can create a computer program solely by using a graphically based programming environment. This graphically based programming environment may be used for creating virtual instrumentation systems, modeling processes, control, simulation and numerical analysis, as well as for any type of general programming.
In creating a graphical program, a user may create or otherwise specify a front panel or user interface panel. The front panel may include various user interface elements or front panel objects, such as controls and/or indicators, that represent or display the respective input and output that will be used by the graphical program or VI, and may include other icons which represent devices being controlled. The front panel may be comprised in a single window of user interface elements, or may comprise a plurality of individual windows each having a user interface element, wherein the individual windows may optionally be tiled together. When the controls and indicators are created in the front panel, corresponding icons or terminals may be automatically created in the block diagram by the block diagram editor. Alternatively, the user can place terminal icons in the block diagram which may cause the display of corresponding front panel objects in the front panel, either at edit time or later at run time. As another example, the front panel objects, e.g., the GUI, may be embedded in the block diagram.
During creation of the block diagram portion of the graphical program, the user may select various function nodes or icons that accomplish his desired result and connect the function nodes together. For example, the function nodes may be connected in one or more Of a data flow, control flow, and/or execution flow format. The function nodes may also be connected in a xe2x80x9csignal flowxe2x80x9d format, which is a subset of data flow. The function nodes may be connected between the terminals of the various user interface elements, e.g., between the respective controls and indicators. Thus the user may create or assemble a graphical program, referred to as a block diagram, graphically representing the desired process. The assembled graphical program may be represented in the memory of the computer system as data structures. The assembled graphical program, i.e., these data structures, may then be compiled or interpreted to produce machine language that accomplishes the desired method or process as shown in the block diagram.
Input data to a graphical program may be received from any of various sources, such as from a device, unit under test, a process being measured or controlled, another computer program, or from a file. Also, a user may input data to a graphical program or virtual instrument using front panel controls. This input data may propagate through the data flow block diagram or graphical program and appear as changes on the output indicators. In an instrumentation application, the front panel can be analogized to the front panel of an instrument. In an industrial automation application the front panel can be analogized to the MMI (Man Machine Interface) of a device. The user may adjust the controls on the front panel to affect the input and view the output on the respective indicators. Alternatively, the front panel may be used merely to view the input and output, or just the output, and the input may not be interactively manipulable by the user during program execution.
Thus, graphical programming has become a powerful tool available to programmers. Graphical programming environments such as the National Instruments LabVIEW product have become very popular. Tools such as LabVIEW have greatly increased the productivity of programmers, and increasing numbers of programmers are using graphical programming environments to develop their software applications. In particular, graphical programming tools are being used for test and measurement, data acquisition, process control, man machine interface (MMI), supervisory control and data acquisition (SCADA) applications, simulation, machine vision applications, and motion control, among others.
Computer programs, including graphical programs, are often required to exchange data with a data source or data target external to the program. In modern networked computer systems, a software program may be required to obtain data from various sources, including local memory on the computer system, external data sources connected to the computer system, such as I/O devices connected to computer system ports, other networked computer systems, or other networked devices. Thus, in various applications, a program may write or provide data of any of various types to any of various types of data targets. Also, in various applications, a program may receive data of any of various types from any of various types of data sources.
For example, data may be received from a data source such as a file or from a server, such as an FTP or HTTP server. The data may comprise static data, such as prestored data in a file, or live data, such as data streamed in real time by a server. The data may also originate from another program or process running on the host computer system or a remote computer system. For example, a program for processing live weather data may utilize data received from a remote computer system that senses weather-related variables, such as temperature, wind speed, humidity, etc., and transduces these variables into data that the program can use.
One of the biggest challenges in developing complex applications that are comprised of different components is sharing and exchanging information and data between the different programs or components. Today, this task is solved using a number of different existing tools, including writing and reading files, DDE, ActiveX automation, http server and client tools, and more. As well known in the art, exchanging data with data sources or data targets external to a program is often difficult to implement. When a program executing on a computer system is required to access data, the program is often required to account for the source or location of the data, opening and closing of files, the format of the data, and conversion of the data to readable formats, among others.
For example, consider the program described above for processing weather data, wherein a client computer system that executes a client program is connected over a TCP/IP network to a server computer that generates the data. In order for the client program to receive the data from the server computer, the TCP protocol would typically be used, which may involve several steps, such as:
choosing a TCP/IP port number not in use by any other applications
defining the application-level protocol (e.g., what gets sent when)
configuring the server computer to listen on the selected port and create a connection when the client program initiates a request
configuring the server computer to marshal the data and write to all connections
configuring the client program to connect to the selected port and unmarshal the data
managing any errors
This list only provides an overview of the complexity involved in receiving the data. Thus, this scenario illustrates several details that many graphical program developers would not have the necessary skill to deal with or would prefer not to deal with. Therefore, it would be desirable to provide a system and method to simplify the task of implementing data exchange for a graphical program.
Ideally, such a system and method would be independent of the type of data source or data target. For example, in the prior art, receiving data from a file would typically require the developer to code a different set of steps than if data were received from a remote server, as described in the above example. For example, the developer may need to program the steps of opening the file, reading data from the file, closing the file, etc. It would be desirable, for example, for a method of configuring a graphical program to receive waveform data from a local file to be the same or substantially the same as a method of configuring the graphical program to receive live waveform data generated by a remote application.
It would also be desirable for the system and method to be independent of the platform on which the program runs. Different computing platforms support different mechanisms for data exchange. For example, a Windows program may use DDE or ActiveX/COM, whereas programs running on other platforms use different mechanisms. In typical cases, graphical program developers would prefer to not concern themselves with platform-specific issues.
Hence, an improved system and method is desired for providing the ability to easily create graphical programs which can access data from/to various sources or targets and having various types or formats, wherein the access is performed invisibly to the user or programmer.
One embodiment of the present invention comprises a system and method for creating a graphical program which accesses data from/to one or more of a data source or a data target. The present invention greatly simplifies the task of creating or configuring a graphical program to exchange data with a data source and/or data target.
The method may operate in a computer including a display screen and a user input device. The computer may be coupled to a network, wherein the data source or the data target may comprise a device coupled to the network. The device may be a second computer system coupled to the network or an instrument coupled to the network.
When a user is creating or configuring a graphical program, the user may cause various nodes or icons to be displayed on the display. The user may then connect the various nodes or icons together in one or more of a data flow, control flow or execution flow format. If the user desires the graphical program to access data from/to one or more of a data source or a data target, the user may cause to be displayed a data access node in the graphical program. For example, the user may select the data access node from a palette or menu and xe2x80x9cdrag and dropxe2x80x9d the node into the graphical program on the display. Thus, the user may arrange a plurality of nodes on the display, wherein the plurality of nodes include the data access node, and may connect the plurality of nodes together to create the graphical program.
The user may then configure the data access node with location information of one or more of a data source or a data target. For example, the user may provide a URL specifying a location of the data source or the data target. In one embodiment, the computer may store a description of the data sources and/or data targets in the computer. When the user indicates an interest in configuring the data access node, e.g., by selecting a data access node, the computer may display a list of data sources and/or data targets. The user may then provide input to select one or more of the data sources and/or data targets from the list.
Configuration of the data access node may comprise the user causing to be displayed an icon or node in the graphical program which references data source/target location information, e.g., which references a URL, and then associating the icon or node with the data access node. The user may associate the icon or node with the data access node by connecting the icon to the data access node or by dragging and dropping the icon onto the data access node. In this embodiment, the icon is operable to provide the data source/target location information to the data access node during execution of the graphical program. In another embodiment, the user may specify the data source/target using a dialog box or property panel for configuring the data access node.
The computer system may then construct execution instructions in response to the graphical program, wherein the execution instructions are executable to access data from/to the one or more of the data source or the data target. The execution instructions may then be executed, wherein the data access node accesses data from/to the one or more of the data source or the data target during execution.
During execution of the graphical program, the data access node is operable to 1) connect to the one or more of the data source or the data target using a reference to the data source or the data target; and 2) acquire data from/publish data to the one or more of the data source or the data target. The data access node may also be operable to convert received data or data to be transmitted from/to a format useable by the graphical program or the data target, such as a generic format or a self-describing format. Thus, during execution of the graphical program, the data access node is operable to access data from/to the one or more of the data source or the data target. If the data access node is configured to access a data source, then during execution of the graphical program the data access node is operable to acquire data from the data source. If the data access node is configured to access a data target, then during execution of the graphical program the data access node is operable to publish data to the data target. Where the data is live data, the data access node may be operable to continually access live data from/to the data source or the data target.
Where the data access node is configured to acquire data from a data source, the data access node may comprise one or more output terminals, and the user may connect the one or more output terminals of the data access node to one or more other nodes in the graphical program. During execution of the graphical program, the data access node may acquire data from the data source and provide the data to the one or more other nodes in the graphical program. The data access node may also optionally convert the data to a format understandable by the other nodes in the graphical program. In a similar manner, where the data access node is configured to publish data to a data target, the user may connect the one or more input terminals of the data access node to one or more other nodes in the graphical program. During execution of the graphical program, the one or more other nodes in the graphical program may provide data to the one or more input terminals of the data access node, and the data access node may publish the data to the data target. The data access node may also optionally convert the data received from the one or more other nodes to a format understandable by the data target.
In one embodiment, the data access node in the graphical program may comprise a xe2x80x9cDataSocketxe2x80x9d node. DataSocket technology provides a single, unified, end-user application programming interface (API) for connecting to data from a number of sources, such as local files, files on FTP or Web servers, and data items on OPC Servers. A DataSocket node specifies the data location by using a familiar networking standard, the URL. Just as a Web browser uses a URL to connect to a Web page, a DataSocket application uses a URL to connect to data. In addition, the DataSocket Transfer Protocol connects a DataSocket application to live data by specifying a connection to a DataSocket Server. The DataSocket Server manages most of the networking tasks for the developer.
With conventional technologies such as TCP/IP, the developer would have to write code to convert data to an unstructured stream of bytes in the broadcasting application, as well as code to parse the stream of bytes back into its original form in subscribing applications. DataSocket, however, transfers data in a self-describing format that can represent data in an unlimited number of formats, including strings, scalars, Booleans, and waveforms. The DataSocket read and write operations transparently convert data to and from the underlying byte streams, eliminating the need to write complicated parsing code. DataSocket uses the DataSocket Transport Protocol (DSTP), referred to above, to send data to and receive data from a DataSocket server.